Danny Amor's Online Library

home *** CD-ROM | disk | FTP | other *** search

/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / mail / majordomo-faq < prev next >

Wrap

Text File | 1995-07-25 | 30.3 KB | 758 lines

Subject: Majordomo Frequently Asked Questions Newsgroups: comp.mail.misc,comp.mail.sendmail,comp.mail.smail,comp.answers,news.answers From: barr@pop.psu.edu (David Barr) Date: 30 Oct 1994 10:03:06 -0500 Version: $Id: majordomo-faq.html,v 1.22 1994/10/25 20:47:06 barr Exp barr $ Archive-Name: mail/majordomo-faq Posting-Frequency: monthly Table of Contents: 1. What is Majordomo and how can I get it? + What is Majordomo? + Where do I get it? + How do I install it? + How do I upgrade from an earlier release? + Where do I report bugs or get help with Majordomo? + Which is better, Majordomo or LISTSERV? 2. Problems setting up Majordomo + I get an error "insecure usage" from the wrapper + I get "majordomo: No such file or directory" from the wrapper + I get an error "Can't locate majordomo.pl" + I get "Permission denied at ..." when majordomo runs + I told majordomo where to archive the list, why isn't it working? + Majordomo seems to be taking many minutes to process commands + I'm accumulating lots of files called /tmp/resend.*.in and .out, 3. Setting up mailing lists and aliases + Handling bounced mail + Semi-automated handling of bounced mail + What's this Owner-List and List-Owner stuff? Why both? + How should I configure resend for Reply-To headers? + How can I hide lists so they can't be viewed by 'lists'? + Can I have the list owner or approval person be changeable without intervention from the Majordomo owner? + What about all of these passwords starting in version 1.90? + How do I tell majordomo to handle "get"-ing of binary files? + A list is visible via lists, but can't subscribe or 'get' files 4. Miscellaneous mailer and other problems + Address with blanks are being treated separately + Why aren't my digests going out? This FAQ is Copyright 1994 by David Barr and The Pennsylvania State University. This document may be reproduced, so long as it is kept in its entirety and in its original format. Credits: originally written by Vincent D. Skahan. Many thanks to the members of the majordomo-workers and majordomo-users mailing lists for many of the questions and answers found in this FAQ. Thanks to fen@comedia.com (Fen Labalme) for getting an HTML version started. You can get this FAQ by sending an e-mail message to majordomo@pop.psu.edu with "get file majordomo-faq" in the body of the message. You can get an HTML version on the World Wide Web at http://www.pop.psu.edu/~barr/majordomo-faq.html. If you have any questions or submissions regarding this FAQ, send them to barr@pop.psu.edu (David Barr). _________________________________________________________________ Section 1: What is Majordomo and how can I get it? WHAT IS MAJORDOMO? Majordomo is a program which automates the management of Internet mailing lists. Commands are sent to Majordomo via electronic mail to handle all aspects of list maintainance. Once a list is set up, virtually all operations can be performed remotely, requiring no intervention upon the postmaster of the list site. majordomo - n: a person who speaks, makes arrangements, or takes charge for another. From latin "major domus" - "master of the house". Majordomo is written in Perl (at least 4.035, preferably 4.036). It is also known to work under Perl 5, if you edit majordomo and resend and look for instances of the "@" character inside text strings "@" Change the "@" to "\@". This only happened with recent versions of Perl 5. The same fix is also required if you want to run Majordomo under OSF/1 on the DEC AXP systems with Perl 4 or 5. [from Jim Reisert] Majordomo controls a list of addresses for some mail transport system (like sendmail or smail) to handle. Majordomo itself performs no mail delivery (though it has scripts to format and archive messages). Here's a short list of some of the features of Majordomo. * supports various types of lists, including moderated ones. * List options can be set easily through a configuration file, editable remotely. * Supports archival and remote retrieval of messages. * Supports digests. * Written in Perl, - easily customizable and expandable. * Modular in design. * Includes support for FTPMAIL. WHERE DO I GET IT? Via anonymous FTP at: ftp://ftp.greatcircle.com/pub/majordomo/ If you don't have Perl, you can get it from: ftp://prep.ai.mit.edu/pub/gnu/perl-4.036.tar.gz The FTPMAIL package can be found in ftp://src.doc.ic.ac.uk/packages/ftpmail or any comp.sources.misc archive (volume 37). HOW DO I INSTALL IT? Majordomo comes with a rather extensive README. Read this file completely. This FAQ is meant to be a supplement to Majordomo's documentation, not a replacement for it. If you have any questions that this FAQ doesn't cover, chances are that it is covered in the README or other documentation in the Majordomo distribution. HOW DO I UPGRADE FROM AN EARLIER RELEASE? Be sure to browse the "Changes" and "Changelog" files to get an idea what has changed. There currently is no canned set of instructions for upgrading from an earlier release. The most straightforward method is to simply install the current release in a different directory, (with the same list/archive/digest directories) and change the mail aliases for each list to use the new Majordomo scripts as soon as you feel comfortable with the new setup. WHERE DO I REPORT BUGS OR GET HELP WITH MAJORDOMO? If you need help, there is a mailing list majordomo-workers@greatcircle.com, which is frequented by lots of users of Majordomo. Please don't send questions to me. Report bugs to majordomo-workers@greatcircle.com. Be sure always to include which version of Majordomo you are using. You should also include what operating system you are using, what version of Perl, and what mailer (sendmail, smail, etc) and version you are using, especially if you can't get Majordomo to work at all. But first, you must have thoroughly read the documentation to Majordomo and this FAQ. WHICH IS BETTER, MAJORDOMO OR LISTSERV? Here's a slight revision of something Chris Koenigsberg posted to comp.mail.misc, following up a thread there. Tasos, the author of ListProc, said that he was basically on the mark concerning ListProc. [ This section is currently under revision --Dave ] Chris Koenigsberg: ckk@uchicago.edu, ckoenig@midway.uchicago.edu U. of Chicago Academic Information Technologies The real LISTSERV (Revised LISTSERV) relies on Bitnet networking transport protocols. A complex Unix list processor was written, in a partial emulation of the Bitnet LISTSERV. The "LISTSERV for Unix" system was renamed "ListProc" last summer, after threats from the original LISTSERV author, because it differs in user interface and list owner interface from LISTSERV, and was accused of misleading users who would confuse it with the "real thing". Majordomo was written, in Perl, because ListProc (AKA Unix LISTSERV) was too complex and did not do quite what was needed to manage a set of Usenix SAGE mailing lists. LISTSERV and ListProc want the whole world to be interconnected, i.e. all mailing list server hosts can know about each other and exchange info on remote lists; someday I imagine there'll be a DNS-like namespace of mailing lists and server hosts out there somehow. Majordomo, on the other hand, is a much smaller package, designed for easier administration on an individual host, and I have even heard (on the Majordomo-Users list) that some Majordomo hosts do NOT wish their lists advertised publicly on the net. We (U. of Chicago Academic Information Technologies) are planning to go ahead and offer new campus list management service soon using Majordomo, but we did have some requests from faculty to use ListProc (they asked for LISTSERV but since this is on Unix, they would have to get ListProc instead). I tried briefly to configure and build ListProc for a comparison test, but gave up when it got weird, probably too soon, maybe I'll try again when I have more time to play with compilers etc :-) Listproc documentation etc. is a bit cryptic and not well thought out overall, at least from the point of view of someone new to the concept trying to understand all of its complex workings. I have seen correspondence from the Listproc author, on the ListProc users' mailing list archives, where he defends his documentation because it is in the usual Unix style. (maybe "damning by faint praise"? :-) Majordomo is simpler and written in Perl scripts, so documentation is more comprehensive, and is improving, as an active community of developers is contributing to it. It only took 2 days for the current maintainers to put out small patches to fix some recently-discovered potential security holes, and since it's Perl, no recompilation is needed. Listproc requires a server daemon to be alive, which forks off child processes somewhat like lpd, and appears to be designed to do a lot of complex, tricky things which requires a lot of C source code doing networking stuff (multi-level automated archiving and indexing, with retrieval via ftpmail, automatic digestification creation and propagation, remote cooperation of "peer" list hosts, interactive administration via TCP connections, operation over other transport and delivery protocols besides TCP and SMTP, maintain its own message queueing system independently of the system mail queues, ...), which are perhaps overkill (for us, in a completely Internet TCP/SMTP environment), perhaps not, this is what I'd like to hear more discussion about. Majordomo is more focused on the essentials of individual mailing list management, and is implemented as Perl scripts, which are modular and can be used in subsets, as they are individually invoked out of system mail aliases. It lets the underlying system software do the networking and message queueing stuff, so it doesn't have to deal with TCP sockets etc. Majordomo's recently-added archiving, digestification, etc. is simpler than ListProc's, and is undergoing more improvements. Apparently, Listproc's daemon with its own queueing system used to give better performance, for high-traffic lists on heavily loaded server hosts, than older versions of sendmail. But now, newer sendmail versions have greatly improved efficiency so Majordomo with new sendmail may be just as fast and load-capable as a Listproc system. (comments welcomed on this point?) With Listproc, if you can get it configured and running smoothly, you can apparently join a growing inter-operating network of cooperating "peer" list hosts, and even inter-operate with Bitnet LISTSERV list hosts too. Thus your local users can easily find out about other lists elsewhere, you can have local re-distributions for a larger global list, etc. (but re-distributions can be a source of administrative headache when global list owners try to track down mysterious errors, or unsubscribe requests from people who aren't subscribed to the global list.... :-). One big flaw in Listproc's design, in my opinion (correct me if I'm wrong!), is that it does funny things to the headers of outgoing messages which are arguably "wrong" in the RFC 822 SMTP world (I've seen arguments in the ListProc users' archives), and for incoming messages, it only uses the Unix From field (i.e. the SMTP Envelope MAIL FROM, in the SMTP world) to determine the sender's identity, for subscribing, unsubscribing, accepting or rejecting messages, etc. Majordomo on the other hand will use the RFC 822 headers (Gene Spafford's Perl code for parsing mail headers), so it will recognize a "Reply-To:" for example, and will allow you to subscribe your canonical address, even if the return path of your message is convoluted (although the list owner may need to approve your subscription). You have various per-list configuration options, about what appears in the various RFC 822/SMTP headers, concerning the return address for errors, the default reply address (to the list, to the original author, to the list owner/moderator, etc.)... Both Listproc and Majordomo share concepts like moderated lists. Listproc's moderated lists have a queue of incoming messages, and the moderator has to approve or reject them by giving the message queue numbers to the server, in order to clear the queue. For a moderated list, Majordomo simply bounces messages to the moderator and then forgets about them, so the moderator can easily re-submit them with an approval password in a new header. Any message arriving with the proper approval password header will be automatically approved and propagated to the list. An outfit called CREN, an offshoot of Educom, has taken over the development of both the Bitnet LISTSERV, and the Unix Listproc, and is planning to offer a commercial version of Listproc sometime later in 1994. They have a global vision building on the inter-operating "peer" list host concept, integrating gopher, ftp, etc. (their vision statement doesn't mention WWW but I assume that must be added soon :-). We are very interested to see if CREN's new Listproc version will come with improved support, including better documentation, and we might consider switching to it sometime in the future, but we are planning to stick with Majordomo for now. _________________________________________________________________ Section 2: Problems setting up Majordomo I GET AN ERROR "INSECURE USAGE" FROM THE WRAPPER The argument to ".../wrapper" should be simply "majordomo", not The full path to majordomo or resend. "wrapper" has where to look compiled in to it (the "W_BIN" setting in the Makefile) for security reasons, and will not let you specify another directory. Your alias should say: |"/path/to/majordomo/wrapper majordomo" I GET "MAJORDOMO: NO SUCH FILE OR DIRECTORY" FROM THE WRAPPER Make sure that the #! statement at the beginning of all the Majordomo Perl executables contain the correct path to the perl program. (the default is /usr/local/bin/perl) Make sure also that majordomo and all the related scripts are in the W_BIN directory as defined in the Makefile when you compiled the wrapper. I GET AN ERROR "CAN'T LOCATE MAJORDOMO.PL" > Whenever I send either mail to a list or a command to majordomo, receive > the following: > > Can't locate majordomo.pl in @INC at /usr/majordom/mjdm/resend line 61. > 554 "|/usr/majordom/mjdm/resend -p bulk -l test -f brian -h -s > test-outgoing". > .. unknown mailer error 2 [from Brent Chapman] Majordomo adds "$homedir" from the majordomo.cf file to the @INC array before it goes looking for "majordomo.pl". Since it's not finding it, I'd guess you have one of two problems: 1) $homedir is set improperly (or not set at all; there is no default) in your majordomo.cf file. 2) majordomo.pl is not in $homedir, or is not readable. [from John P. Rouillard] 3) Note that the new majordomo.cf file checks to see if the environment variable $HOME is set first, and uses that for $homedir. Since the wrapper always sets HOME to the correct directory, you get a nice default, unless you are running a previously built wrapper, in which case you may get the wrong directory. [from Andreas Fenner] 4) I had the same problem when I installed majordomo (1.62). My Problem was a missing ";" in the majordomo.cf file - just in the line before setting homedir .... My hint for you: Check your perl-files carefully. I GET "PERMISSION DENIED AT ..." WHEN MAJORDOMO RUNS > > shlock: open(">/usr/local/lib/majordomo/shlock.15260"): > Permission denied at /usr/local/lib/majordomo/shlock.pl line 131, > line 7. The directory "/usr/local/lib/majordomo" needs to be writable by the uid/gid that the "wrapper" program run as, so that Majordomo can create its lock file. In general, for any file Majordomo writes, both the file _AND_ the directory the file is in must be writable by Majordomo, so that it can create lock files and new versions of the data file (Majordomo usually "updates" a file by creating "file.new" and then, when that has succeeded, deleting "file" and renaming "file.new" to "file"). > Also, should everything in my majordomo directory by owned by > majordom and the group set to majordom? Basically, yes, and it should all (including the directory itself) be writable by whatever uid/gid wrapper is set to run as. I TOLD MAJORDOMO WHERE TO ARCHIVE THE LIST, WHY ISN'T IT WORKING? > I don't get it: is the list archive a file or a directory? > I chose directory and it doesn't work, though I'm not sure why. > The relevant majordomo.cf entry looks like: > $filedir = "/usr/local/mail/majordomo/archive"; > $filedir_suffix = ""; [From John Rouillard] The archive variables in majordomo.cf aren't used to archive anything. You have to use a separate archive program, or a sendmail alias to do the archiving. The info is used to generate a directory where the archive files are being placed by some other mechanism. You are telling majordomo to look in the directory: /usr/local/mail/majordomo/archive/ for files that it should allow to be gotten using the get command. Majordomo comes with three different archive programs that run under wrapper, that do various types of archiving. Look in the contrib directory. MAJORDOMO SEEMS TO BE TAKING MANY MINUTES TO PROCESS COMMANDS > Commands are being processed at the rate of about one every 10 minutes. > What's going wrong, why is Majordomo so slow? Majordomo tries to lock the log file (by creating a lock file in the directory with the log file) for 10 minutes for each log message, before giving up. It's typically going to log one log message for each command in the input. If the directory containing the file is not writable by the Majordomo user/group, then majordomo won't be able to lock the file and thus will take a very long time to process commands. Check the permissions on the log file and all the directories where majordomo files are located. Double-check the permission on the wrapper. If you are on a non-POSIX system, it must be both suid and sgid (mode 6755) to whatever you defined your majordomo user and group to be. It must not be setuid root! OR In a POSIX system the wrapper must be setuid root, and double-check that W_UID and W_GID are of the majordomo user and group. Don't set W_UID to be 0! I'M ACCUMULATING LOTS OF FILES CALLED /TMP/RESEND.*.IN AND .OUT WHAT ARE THESE AND HOW CAN I GET RID OF THEM? This is a known bug in Majordomo 1.92. There was a typo in resend on line 347. Change the double-quotes to angle-brackets. (just like the other calls to unlink()) _________________________________________________________________ Section 3: Setting up mailing lists and aliases HANDLING BOUNCED MAIL > If a subscriber sends a message to a mailing list containing addresses > that cause bounces, then the subscriber/sender gets a copy of the > bounced mail. They don't care to receive the bounce. Can this be > prevented? (Without removing the offending addresses from the list -- > I'm aware of the Majordomo 'bounce' utility.) This was somewhat of a RTFM question. The answer is to use 'resend' to your advantage. The following is an example of a sendmail alias that I was using: sample: :include:/usr/local/mail/lists/sample Whereas this example (from the 'sample.aliases' file distributed with Majordomo) fixes the problem. sample: "|/usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Sample -f Owner-Sample -h GreatCircle.COM -s sample-outgoing" sample-outgoing: :include:/usr/local/mail/lists/sample owner-sample: joe See the 'resend.README' file for more info on resend's options. What this does is force outgoing mail to have the out-of-band envelope FROM be "Owner-Sample@GreatCircle.COM", and thus all bounces will be redirected to that address. (Users often see this mirrored in the message body as the "From " or "Return-Path:" header). 'resend' also inserts a "Sender:" line with the same address to help people identify where it came from, but that header is not used for the bounce address. If you are using sendmail v8.x, you don't have to use 'resend' to do the same thing. You simply have to define an alias like this: owner-sample: joe, Note the trailing comma is necessary to prevent sendmail from resolving the alias first before putting it in the header. Without the comma, it will put "joe" in the envelope from instead of "owner-sample". Either address will work, of course, but the generic address is preferred should the owner ever change. SEMI-AUTOMATED HANDLING OF BOUNCED MAIL >The documentation, I guess, isn't very clear on this, but how does one >implement the bounce list/bounce-remind program so that people that go >'boing' can be dealt with in a somewhat more automated manner? > >Uh . . . how exactly is this accomplished? [From John Rouillard] There is nothing special about this. Just create a mailing list called bounces. I usually set mine up as an auto list just to make life easier. All that bounce does is create an email message to that says: approve [passwd] unsubscribe [listname] [address] approve [passwd] subscribe bounces [address] The [address] and [listname], are given on the command line to bounce. The address of the majordomo, and the passwords are retrieved from the .majordomo file in your home directory. A sample .majordomo file might look like (shamelessly stolen from the comments at the top of the bounce script): this-list passwd1 Majordomo@This.COM other-list passwd2 Majordomo@Other.GOV bounces passwd3 Majordomo@This.COM bounces passwd4 Majordomo@Other.GOV A command of "bounce this-list user@fubar.com" will mail the following message to Majordomo@This.COM: approve passwd1 unsubscribe this-list user@fubar.com approve passwd3 subscribe bounces user@fubar.com (930401 this-list) while a command of "bounce other-list user@fubar.com" will mail the following message to Majordomo@Other.COM: approve passwd2 unsubscribe other-list user@fubar.com approve passwd4 subscribe bounces user@fubar.com (930401 this-list) Note that the date and the list the user was bounced from are included as a comment in the address used for the "subscribe bounces" command. WHAT'S THIS OWNER-LIST AND LIST-OWNER STUFF? WHY BOTH? [From David Barr] The "standard" is spelled out in RFC 1211 - "Problems with the Maintenance of Large Mailing Lists". It's here where the "owner-listname" and "listname-request" concepts got their start. (well it was before this, but this is where it was first spelled out) Personally, I don't use "listname-owner" anywhere. You don't really have to put both, since the "owner" alias is usually only for bounces, which you add automatically anyway with resend's "-f" flag, or having Sendmail v8.x's "owner-listname" alias. (while I'm on the subject) The "-approval" is a Majordomo-ism, and is only necessary if you want bounces and approval notices to go to different mailboxes. (though you'll have to edit some code in majordomo and request-answer if you want to get rid of the -approval alias, since it's currently hardwired in) So, to answer your question, I'd say "no". You don't have to have both. You should just have "owner-list". HOW SHOULD I CONFIGURE RESEND FOR REPLY-TO HEADERS? Whether you should have a "Reply-To:" or not depends on the charter of your list and the nature of its users. If the list is a discussion list and you generally want replies to go back to the list, you can include one. Some people don't like being told what to do, and prefer to be able to choose whether to send a private reply or a reply to the list just by using the right function on their mail agent. Take note that if you do use a "Reply-To:", then some mail agents make it much harder for a person on the list to send a private reply. If you are using resend, use the '-r ' flag to set the Reply-To field to the list, or use the 'reply_to' config keyword for 1.9x or greater. HOW CAN I HIDE LISTS SO THEY CAN'T BE VIEWED BY 'LISTS'? That is what advertise and noadvertise are for. The two keywords take regular expressions that are matched against the from address of the sender. A list display follows the rules: 1. If the from address is on the list, it is shown. 2. If the from address matches a regexp in noadvertise (e.g. /.*/) the list is not shown. 3. If the advertise list is empty, the list is shown unless 2 applies. 4. If the advertise list is non-empty, the from address must match an address in advertise. Otherwise the list is not shown. Rule 2 applies, so you could allow all hosts in umb.edu except hosts in cs.umb.edu. CAN I HAVE THE LIST OWNER OR APPROVAL PERSON BE CHANGEABLE WITHOUT INTERVENTION FROM THE MAJORDOMO OWNER? Sure! Just make owner-listname and/or listname-approval be another majordomo list. (probably hidden, for simplicity's sake) WHAT ABOUT ALL OF THESE PASSWORDS STARTING IN VERSION 1.90? Think of three separate passwords: 1. A master password that can be used by both resend and majordomo contained in [listname].passwd. To be used by the master list manager when using writeconfig commands etc. This allows someone who handles a number of mailing lists all using the same password. 2. A password for the manager of this one list. The admin_passwd can be used by subsidiary majordomo list maintainers. 3. A password for those concerned with the list content (approve_passwd) This way the administration and moderation functions can be split. The original reason for maintaining [listname].passwd was to allow a new config file to be put in if the config file was trashed and the admin_password was obliterated, and may still be useful to allow a single password to be used for admin functions by the majordomo admin or some other "superadmin". > [...stupid question - is the admin passwd in the config file a file name > or the password itself for the list ? ...] The password itself. This is the only way that the list-maintainer could change the password since they wouldn't have access to the file. HOW DO I TELL MAJORDOMO TO HANDLE "GET"-ING OF BINARY FILES? Majordomo is not designed to be a general-purpose file-by-mail system. If you want to do anything more than trivial "get"-ing of text files (archives, etc) than you should get and install ftpmail. Majordomo has hooks to allow transparent access to files via ftpmail (see majordomo.cf). A LIST IS VISIBLE VIA LISTS, BUT CAN'T SUBSCRIBE OR 'GET' FILES [From Brent Chapman] I'll bet your list name has capital letters in it... Majordomo smashes all list names to all-lower-case before attempting to use the list name as part of a filename. So, while it's OK to advertise (for instance) "Majordomo-Users" and have the headers say "Majordomo-Users", the files and archive directory all need to be "majordomo-users*". _________________________________________________________________ Section 4: Miscellaneous mailer problems ADDRESS WITH BLANKS ARE BEING TREATED SEPARATELY > Does anyone else have the problem: > > If a subscriber to the list is > John Doe > > Majordomo or sendmail treats this as 3 addresses: > John > Doe > > > Of course the first two always fail. [From Alan Millar] Majordomo does not treat these as three addresses. Your apparent version of Sendmail does. Remember that all Majordomo does is add and remove addresses from a list. Majordomo does not interpret the contents of the list for message distribution; the system mailer (such as sendmail) does. I'm using SMail3 instead of sendmail, and it has an alternative (read "stupid") view of how mixed angle-bracketed and non-angle-bracketed addresses should be interpreted. I found that putting a comma at the end of each line was effective to fix the problem, and I got to keep my comments. So I patched Majordomo to add the comment at the end of each address it writes to the list file. You can also add the $listname.strip option so that none of the addresses are angle-bracketed. (the "strip" config option for 1.90) WHY AREN'T MY DIGESTS GOING OUT? >I'm not sure how to set up the digest feature of majordomo 1.92 to send >digests out. Currently, it is digesting incoming mail, but that's all it's >doing. [from John Rouillard] echo mkdigest | mail majordomo@... This will force a digest to be created. Or you can set the max size in the digest list config file down low, and force automatic generation. There are some patches for 1.92 that will allow other ways of specifying automatic digest sending. The patch is in the contrib directory.